[% setvar title The Perl 6 Summary for the week ending 20021110 %]
<div id="archive-notice">
    <h3>This file is part of the Perl 6 Archive</h3>
    <p>To see what is currently happening visit <a href="http://www.perl6.org/">http://www.perl6.org/</a></p>
</div>
<div class='pod'>
<a name='The Perl 6 Summary for the week ending 20021110'></a><h1>The Perl 6 Summary for the week ending 20021110</h1>
<p>Far off in distant Newark a figure, muttering something about `Leon
Brocard', shambles across a railway bridge and makes its way into a
waiting room. Time passes. After a while, a train arrives and the
figure shambles on board, takes its seat, pulls a laptop from its bag
and starts to type. This is what it types: `=head1 The Perl 6 Summary
for the week ending 20021110'.</p>
<p>Yes, it's time for another update on the japes and tomfoolery from the
world of Perl 6. We start, as usual, with perl6-internals.</p>
<a name='The Myth of Fingerprints'></a><h2>The Myth of Fingerprints</h2>
<p>At the end of the previous week, Gregor posted an outline of his
proposal for fixing the fingerprinting issue with dynamic
loading. (The fingerprinting issue is that 'old' .pbc files may break
big time when run on newer Parrots. Ideally we'd like Parrot to refuse
to run such files <i>before</i> bad things happen. It's proposed that this
be done by adding `fingerprints' to .pbc to allow for identification
by Parrot.) Leopold T<ouml>tsch wasn't at all sure about Gregor's
approach, pointing out that it would have massive speed
implications, and lo, the thread got dragged off in the direction of a
discussion of optimizing Parrot for speed. How did that happen then?</p>
<p><a href='http://groups.google.com/groups?threadm=OFD709CD11.B32BE727-ON85256C66.0074F03C-85256C66.0077A25A@kennedytech.com' target='_blank'>groups.google.com</a></p>
<a name='on_exit not portable'></a><h2><code>on_exit</code> not portable</h2>
<p>Andy Dougherty pointed out that Solaris doesn't have <code>on_exit</code>, which
is used by Parrot to clean up after itself, and suggested that
<b><i>interpreter.c</i></b> be reworked to use <code>atexit</code>. However, SunOS
has on_exit but doesn't have atexit. It's a quandary. Josh Wilmes
suggested implementing <code>Parrot_on_exit()</code> and <code>Parrot_exit()</code> in
<b><i>platform.c</i></b> and half promised a patch (unless somebody beat him to
it.) Leo T&ouml;tsch and Nicholas Clark both said, essentially &quot;Nice
idea, go do it.&quot;</p>
<p>Dan chimed in, pointing out that the current <code>on_exit</code> behaviour
seemed to be there as a workaround for bugs in exceptions, and that
fixing those was probably the better idea. Leo turned off the
'on_exit' stuff, just as Josh was sending a patch implementing the
Parrot_* functions. I think that, as we now stand, we're back to doing
exit cleanup, but using the portable Parrot_* functions.</p>
<p><a href='http://groups.google.com/groups?threadm=200211050046.gA50jlJ2007961@galactic.hitchhiker.org' target='_blank'>groups.google.com</a></p>
<p><a href='http://groups.google.com/groups?threadm=a05200f01b9ef129f93a9@' target='_blank'>groups.google.com</a>[63.120.19.221]</p>
<a name='Should memory be washed?'></a><h2>Should memory be washed?</h2>
<p>Peter Gibbs was unsure of the guarantees given by <code>Parrot_allocate</code>
and friends regarding the contents of the memory supplied. Apparently,
some code appears to assume that it will get pre-washed memory, while
other code does its own cleaning. Which is right? Leo T&ouml;tsch
reckons that the current behaviour (memory is zeroed at allocation
time) should be guaranteed. Dan wasn't so sure that this was a good
idea if we go for a `malloc like' scheme and thought that it could be
argued that it was a bug for any code to assume that the memory it got
was zeroed.</p>
<p>Eventual consensus was that the basic allocator should not guarantee
zeroed memory, but that there should be a set of allocator functions
that <i>do</i> return zeroed memory. Leo checked in a patch to that
effect.</p>
<p>Then they started talking about performance.</p>
<p><a href='http://groups.google.com/groups?threadm=04a801c28440$8a85e7c0$0b01010a@emkel.co.za' target='_blank'>groups.google.com</a></p>
<a name='string_set is back'></a><h2><code>string_set</code> is back</h2>
<p>Leopold T&ouml;tsch has added a 'string_set' function which allows
strings to be recycled instead of having to create new strings every
time. This can lead to substantial speed gains when used
appropriately. This led to a discussion on when it was appropriate to
use non destructive assignment and when to use a destructive
set. Somewhat to my surprise, nobody has yet suggested the lispish
<code>set</code> is non destructive, <code>set!</code> is destructive split, allowing the
Parrot coder to choose. Looks like I just suggested it here.</p>
<p><a href='http://groups.google.com/groups?threadm=3DC8D805.2010804@toetsch.at' target='_blank'>groups.google.com</a></p>
<a name='Meanwhile, over in perl6-language'></a><h1>Meanwhile, over in perl6-language</h1>
<p>Amazingly, the main topic of conversation this week wasn't the dreaded
operator thread...</p>
<a name='Unifying invocant and topic naming syntax'></a><h2>Unifying invocant and topic naming syntax</h2>
<p>Allison Randal has written an article about Perl 6 topics for
perl.com. `Ralph' read this and didn't appear to like it very much,
particularly the <code>sub foo ($bar) is given($baz) { ... }</code> syntax
which sets <code>$baz</code> to the value of the caller's topic. (If you're not
sure what I'm talking about, now would be a good time to read
Allison's article. Topics are great, you'll like them.) Ralph wanted
to do <code>sub foo ($baz : $bar is topic) { ... }</code>, and supplied
several further, terser and terser declaration forms, <code>method f
($self : $c : $a*, $b) {...}</code> anyone?</p>
<p>Allison thought Ralph was barking up the wrong tree, and explained the
thinking behind the topic related syntax and pointed out that Ralph
appeared to be conflating two `independent but interacting features'
with his proposal, but Ralph didn't give up that easily. Eventually,
after comments from Damian and Allison he let the subject lie.</p>
<p><a href='http://www.perl.com/pub/a/2002/10/30/topic.html' target='_blank'>www.perl.com</a></p>
<p><a href='http://groups.google.com/groups?threadm=018701c283c1$7d18cfa0$6601a8c0@ralph' target='_blank'>groups.google.com</a></p>
<a name='UTF-8 and Unicode FAQ'></a><h2>UTF-8 and Unicode FAQ</h2>
<p>Actually, I lied about the operator thread subsiding. It
fragmented. But at least now the various fragments got their own
subjects. In this particular subthread the whole 'Unicode operators in
core' thing got discussed. There appear to be two camps. The first
camp maintains that Unicode operators in the core means Perl will
start looking dangerously like APL and will need a space cadet
keyboard to use. The second camp's argument for Unicode operators
appears to be `Yeah, and your point was? We only want to use &laquo;
and &raquo;, and isn't it about time the world got with the Unicode
program?'</p>
<p>Me? I'm on the fence. I can see the reasoning behind wanting Unicode
operators, but I'm not entirely sure I like them (the 'email encoding'
problem is my major bugbear...)</p>
<p><a href='http://groups.google.com/groups?threadm=3DC68794.1040108@vulpes.com' target='_blank'>groups.google.com</a></p>
<p><a href='http://groups.google.com/groups?threadm=26E3E3DB-F110-11D6-A3FD-00050245244A@cognitivity.com' target='_blank'>groups.google.com</a> -- A decent
summation from Michael Lazzaro</p>
<a name='Supercomma!'></a><h2>Supercomma!</h2>
<p>At one point in the UTF-8 and Unicode thread, Larry wondered if he
could raid Unicode for a better character than <code>;</code> for separating
parallel <code>for</code> loop streams. Michael Lazzaro responded with a couple
of suggestions for different supercommas which would have different
meanings. I couldn't tell you what the symbols are, my mailer rendered
'em as Latin-1 digraphs, neither of which looked much like a comma.</p>
<p>Larry then confessed that he was thinking of changing the declaration
of parallel for loops from:</p>
<pre>  for @a ; @b ; @c -&gt; $a ; $b ; $c {...}</pre>
<p>to something like:</p>
<pre>  for parallel(@a, @b, @c) -&gt; $a, $b, $c {...}</pre>
<p>Which has the advantage of not messing with the block signature at
all, which Larry reckons should make Simon Cozens happier. Damian
pointed out that doing things this way would probably mean we'd get a
bunch of useful functions for iterating over arrays (and then
implemented one such function). Others followed, implementing various
other useful functions before Damian capped them all with a nicely
generalized <code>zip</code> implementation.</p>
<p>Buddha Buck endeared himself to the summarizer with his summary of
<code>for</code> loop possibilities. Buddha also included a rather pretty
implementation of <code>for</code> as a recursive function, though Damian
reckoned he'd not quite got the signature right.</p>
<p><a href='http://groups.google.com/groups?threadm=20021104195838.GA24226@london' target='_blank'>groups.google.com</a></p>
<p><a href='http://groups.google.com/groups?threadm=468E095E-F044-11D6-BC89-00050245244A@cognitivity.com' target='_blank'>groups.google.com</a></p>
<p><a href='http://groups.google.com/groups?threadm=3DC83ACA.3070705@conway.org' target='_blank'>groups.google.com</a></p>
<p><a href='http://groups.google.com/groups?threadm=3DC7F320.4020804@14850.com' target='_blank'>groups.google.com</a></p>
<a name='The interminable operator thread'></a><h2>The interminable operator thread</h2>
<p>`Smylers' is my hero of the week for a message he posted summarizing
the various (12) options for changing the look of operators, with
particular reference to vectorization. Options range from `as we were'
to the `guillemot' option which involves seabirds and a pathological
inability to spell `guillemet'.</p>
<p><a href='http://groups.google.com/groups?threadm=20021104231339.80644.qmail@onion.perl.org' target='_blank'>groups.google.com</a></p>
<a name='FMTWYENTK about :='></a><h2>FMTWYENTK about <code>:=</code></h2>
<p>Bravely declining to expand the acronym in his subject, arcardi posted
a summary of his current understanding of the behaviour of <code>:=</code>, the
binding operator, and peppered the post with questions. None of which
got answered this week.</p>
<p><a href='http://groups.google.com/groups?threadm=15816.1795.990706.339369@figaro.weizmann.ac.il' target='_blank'>groups.google.com</a></p>
<a name='Junctions and laziness'></a><h2>Junctions and laziness</h2>
<p>Junctions are what we're calling superpositions this week. Piers
Cawley had another crack (the operative word I think, on rereading) at
his non deterministic search algorithm using junctions and a subclass
of Function. Damian, of course, came up with a better possible syntax
for lazy functions:</p>
<pre>    sub some_func(Num $n) is lazy returns Num {
      return $n ** $n;
    }</pre>
<p>Billy Naylor wondered if a similar notation could
be used for memoize:</p>
<pre>    sub fib(Num $n) is memo returns Num {
      given $n {
        when 0    { 0 }
        when 1    { 1 }
        otherwise { fib($n-1) + $fib($n-2) }
      }
    }</pre>
<p>and Damian pointed out that this was covered in Apocalypse 2, but the
name of the property was yet to be decided. Which led to discussion of
appropriate names.</p>
<p><a href='http://groups.google.com/groups?threadm=84u1iueqpb.fsf@despairon.bofh.org.uk' target='_blank'>groups.google.com</a></p>
<a name='Primitive vs. Object types'></a><h2>Primitive vs. Object types</h2>
<p>David Whipp was worried about the use of primitive types. He pointed
out that &quot;whenever a value passes through a primitive type, it loses
all its run-time properties; and [junctions] will collapse. I worry
that this could cause very obscure bugs&quot;. He also worried that the
similarity of names (<code>Int</code> for an object vs. <code>int</code> for a primitive)
would make such problems harder to spot, and violated Larry's maxim
that `Similar things should look different'. He proposed that, in
order to use primitive types, a module author should first do
something like <code>use primitives qw(int)</code>, and that maybe names like
<code>int</code> should be changed to names like <code>_prim_int32</code>.</p>
<p>Dan wasn't entirely sure that David's basic assumption about
properties/junctions was accurate, but Michael Lazzaro pointed
out that this had been strongly implied by things Larry and Damian had
said, though Michael later dug up a reference to Apocalypse 2 which
was ambiguous about runtime properties on primitive types. Dan started
making 'worried' noises about supporting primitive types and Larry,
while still keeping things fluid about what will actually happen,
explained more of his thoughts about them.</p>
<p>Garrett Goebel wondered about the difference between `attribute' and
`property' in Perl 6. I assume everyone would like to know this. The
very short answer goes something like: `attribute' is the Perl 6 term
for an instance variable, a `property' can be thought of as a
`yellow sticky note attached to an arbitrary object'. Dan has a better
explanation which doesn't avoid using a trademarked term.</p>
<p><a href='http://groups.google.com/groups?threadm=F0DF160193C9D511B7110050DA8B7C2457246B@msexchange.intranet.fast-chip.com' target='_blank'>groups.google.com</a></p>
<p><a href='http://groups.google.com/groups?threadm=a05200f07b9f085dce400@' target='_blank'>groups.google.com</a>[63.120.19.221]</p>
<p><a href='http://groups.google.com/groups?threadm=a05200f02b9f093761431@' target='_blank'>groups.google.com</a>[63.120.19.221] -- Dan's
attributes/properties explanation</p>
<a name='perl6-documentation was born'></a><h2>perl6-documentation was born</h2>
<p>On Wednesday, Michael Lazzaro (who has been doing some sterling
documentation work, check out his `introduction to variables and
values' docs, linked below) proposed that now was the time to start
documenting (and finalizing) the detailed design of what we know about
Perl 6 so far. He is concerned that for all the discussion on the
language list, most of the decisions don't appear to be being
documented, nor reflected back in updated Apocalypses and other
documentation.</p>
<p>He proposed, therefore, that perl6-language `focus on fleshing out
every last detail implied by Apocalypses 2-N, <i>in that order</i>' and hoped
that we could `migrate perl6-language into a list that finalizes
aspects of the design, documents them, and revises them as needed'.</p>
<p>Allison Randal wasn't initially convinced that this was necessarily a
good idea. She worried that Larry (the Official Last Word on Perl 6)
would be snowed under by an RFCesque tide of new documentation, and
that reviewing such a tide would make him lose focus.</p>
<p>At this point, Michael threw the Virtual Coffee Mug.</p>
<p>After a further period of discussion Dan pointed out that the key was
to `Just Do It' (a phrase normally pronounced with four words), so we
created the perl6-documentation mailing list and your summarizer got a
bunch more work.</p>
<p>The thread is long. I've summarized the main line (badly) and
now provide some links to key posts, but if you want more detail I
suggest you follow the first link and read the thread. For those that
like drama and high emotion, the virtual CM chucking post is Michael's
response to Allison's reply. I'm not going to link directly to it;
trust me, context is better.</p>
<p><a href='http://cog.cognitivity.com/perl6/val.html' target='_blank'>cog.cognitivity.com</a> -- vars and values intro</p>
<p><a href='http://groups.google.com/groups?threadm=76134CC0-F11E-11D6-A3FD-00050245244A@cognitivity.com' target='_blank'>groups.google.com</a></p>
<p><a href='http://groups.google.com/groups?threadm=a05200f0cb9ef309c9ae1@' target='_blank'>groups.google.com</a>[63.120.19.221] -- Dan talks sense</p>
<p><a href='http://groups.google.com/groups?threadm=87heeus32d.fsf@simoncozens-2.dsl.easynet.co.uk' target='_blank'>groups.google.com</a> -- So does Simon
Cozens</p>
<p><a href='http://groups.google.com/groups?threadm=a05200f08b9ef2e9320f9@' target='_blank'>groups.google.com</a>[63.120.19.221] -- The tests should be the
spec</p>
<a name='Meanwhile, In perl-documentation'></a><h1>Meanwhile, In perl-documentation</h1>
<p>The new baby got off to a flying start as Michael Lazzaro laid down
his goals for the project. Early discussion centred on the overall
structure of the intended documentation; what formats it should be
written in; the requirements for concrete, executable Perl 6 test
cases and the importance of fluidity. Michael repeatedly stressed that
it was vital that the documentation list retain focus; his goal is
that the entire list should work on one thing at a time.</p>
<p><a href='http://groups.google.com/groups?threadm=3DCC77DA.2704A44@cognitivity.com' target='_blank'>groups.google.com</a></p>
<a name='Roll call'></a><h2>Roll call</h2>
<p>Michael asked for a quick roll call of who was interested in the
documentation project. As an added bonus, he asked that even the
lurkers put their hands up if they were interested. Surprisingly, some
of them decloaked and did so.</p>
<p><a href='http://groups.google.com/groups?threadm=CB2CAEFE-F33C-11D6-AB2D-00050245244A@cognitivity.com' target='_blank'>groups.google.com</a></p>
<a name='Project Goals?'></a><h2>Project Goals?</h2>
<p>Michael formally kicked off the discussion with the question &quot;How can
this documentation project best help with the overall goal of
producing a finished Perl 6?&quot; Answers on a piece of data to the list,
do not attempt to write on both sides of the data at once.</p>
<p><a href='http://groups.google.com/groups?threadm=49FFBC91-F351-11D6-AB2D-00050245244A@cognitivity.com' target='_blank'>groups.google.com</a></p>
<a name='Project Start: Section 1'></a><h2>Project Start: Section 1</h2>
<p>Late on Friday, Michael kicked off discussion of the first
section, most of the discussion of which took place during the
following week. Which is when I'll summarize it.</p>
<p><a href='http://groups.google.com/groups?threadm=3DCEB72C.ED424915@cognitivity.com' target='_blank'>groups.google.com</a></p>
<a name='In Brief'></a><h1>In Brief</h1>
<p>Leo T&ouml;tsch and Brent Dax have been working on ways of making
Parrot GC go faster by improving the performance of the `destroy'
phase.</p>
<p>Andy Dougherty sent in a patch to ensure that the <b><i>languages/perl6</i></b>
build will work without bison. Andy found and fixed a compiler
specific bug introduced by someone using C++ style comments.</p>
<p>Richard Proctor suggested that miniparrot should be called `budgie'.</p>
<p>Leo T&ouml;tsch showed off some numbers for the life generations/sec
test. JIT is looking very quick indeed, it's only around 25% slower
than a native C implementation.</p>
<p>Dan's back from Seattle and digging through his mail backlog.</p>
<p>Leo T&ouml;tsch has been thinking about regexes/patterns/rules and
thinks that we should reintroduce a regex state object, making regexes
reentrant once more.</p>
<a name='Who's who in Perl 6?'></a><h1>Who's who in Perl 6?</h1>
<ul>
<li><a name='Who are you?'></a>Who are you?</li>
<p>Simon Glover</p>
<li><a name='What do you do for/with Perl 6?'></a>What do you do for/with Perl 6?</li>
<p>Write tests, stomp on compiler warnings, fix bugs (occasionally)...</p>
<p>Basically, I try to help out with some of the tedious but necessary
stuff in order to free up other people to concentrate on design &amp;
implementation.</p>
<li><a name='Where are you coming from?'></a>Where are you coming from?</li>
<p>About this time last year, I was starting to get a bit frustrated at
what appeared to me to be the slow pace of Parrot development, when I
suddenly thought: 'You know, if you gave them a hand, they'd finish
sooner'. So I did (and we haven't... yet. Of course, I've now got a
better understanding of <i>why</i> this takes a long time).</p>
<p>I'd also like to add that I'm proof that you don't have to be a C
coder in order to be useful on a project like this...</p>
<li><a name='When do you think Perl 6 will be released?'></a>When do you think Perl 6 will be released?</li>
<p>Depends what you mean by Perl 6 -- after all, we already have a subset
of it up and running on Parrot. Seriously, I think we'll have
something that's genuinely usable and useful well before the end of
2003, even if there are still a few loose ends to tie up.</p>
<li><a name='Why are you doing this?'></a>Why are you doing this?</li>
<p>I like Perl - it matches the way I think. The problem is, Perl is too
slow for many of the things that I'd like to use it for, and too hard
to extend. Parrot should fix both of these problems.</p>
<p>Also, it's nice to see one of my favourite features of F90 finally
make it into Perl :-)</p>
<li><a name='You have 5 words. Describe yourself.'></a>You have 5 words. Describe yourself.</li>
<p>Mild-mannered English computational astrophysicist.</p>
<li><a name='Do you have anything to declare?'></a>Do you have anything to declare?</li>
<p>All the C I know I learnt from Parrot. (Well, OK, K&amp;R helped too, but
it's amazing how much you can learn from reading other people's code).</p>
</ul>
<a name='Acknowledgements, requests and general banter'></a><h1>Acknowledgements, requests and general banter</h1>
<p>This summary was again brought to you from the 0625 Newark on Trent to
Kings Cross and the 1720 Kings Cross to Newark on Trent trains. It was
fuelled by copious amounts of GNER coffee and, one one occasion, a
bacon and tomato toasted sandwich. I'd like to extend my thanks and
best wishes to Avril Hill, who's been bringing me morning tea for
months now, but who's about to escape the train and start working on
Leeds station.</p>
<p>Proofreading services were supplied by aspell and myself. Blame aspell
if it's really terrible.</p>
<p>I'm running short of questionnaire answers. If you've <i>ever</i> been
mentioned in a Perl 6 Summary, or if you haven't (yet), please
consider answering the questions Simon just answered and sending them
to mailto:<a href='mailto:5Ws@bofh.org.uk.'>5Ws@bofh.org.uk.</a> Thanks.</p>
<p>Now, if we all join in with the chorus:</p>
<p>If you didn't like this summary,  what are you doing still reading it?
If you did like it, please consider one or both of the following
options:</p>
<ul>
<li><a name='Send money to the Perl Foundation at donate.perl-foundation.org/ and help support the ongoing development of Perl 6.'></a>Send money to the Perl Foundation at
<a href='http://donate.perl-foundation.org/' target='_blank'>donate.perl-foundation.org</a> and help support the ongoing
development of Perl 6.</li>
<li><a name='Send feedback, flames, money and/or a Schneider 90mm f/5.6 Super Angulon XL to mailto:<a href='mailto:pdcawley@bofh.org.uk'>pdcawley@bofh.org.uk</a>'></a>Send feedback, flames, money and/or a Schneider 90mm f/5.6 Super
Angulon XL to mailto:<a href='mailto:pdcawley@bofh.org.uk'>pdcawley@bofh.org.uk</a></li>
</ul>
<p>The fee paid for publication of these summaries on perl.com is paid
directly to the Perl Foundation.</p>
</div>
